Skip to content

[llvm] Proofread *.rst #151087

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged

Conversation

kazutakahirata
Copy link
Contributor

This patch hyphenates words that are used as adjecives, such as:

  • architecture specific
  • human readable
  • implementation defined
  • language independent
  • language specific
  • machine readable
  • machine specific
  • target independent
  • target specific

This patch hyphenates words that are used as adjecives, such as:

- architecture specific
- human readable
- implementation defined
- language independent
- language specific
- machine readable
- machine specific
- target independent
- target specific
@llvmbot
Copy link
Member

llvmbot commented Jul 29, 2025

@llvm/pr-subscribers-llvm-globalisel
@llvm/pr-subscribers-llvm-ir

@llvm/pr-subscribers-backend-amdgpu

Author: Kazu Hirata (kazutakahirata)

Changes

This patch hyphenates words that are used as adjecives, such as:

  • architecture specific
  • human readable
  • implementation defined
  • language independent
  • language specific
  • machine readable
  • machine specific
  • target independent
  • target specific

Patch is 25.21 KiB, truncated to 20.00 KiB below, full version: https://github.com/llvm/llvm-project/pull/151087.diff

28 Files Affected:

  • (modified) llvm/docs/AMDGPUDwarfExtensionsForHeterogeneousDebugging.rst (+4-4)
  • (modified) llvm/docs/AMDGPUUsage.rst (+1-1)
  • (modified) llvm/docs/CodeGenerator.rst (+3-3)
  • (modified) llvm/docs/CommandGuide/llvm-bcanalyzer.rst (+2-2)
  • (modified) llvm/docs/CommandGuide/llvm-debuginfo-analyzer.rst (+1-1)
  • (modified) llvm/docs/CommandGuide/llvm-exegesis.rst (+1-1)
  • (modified) llvm/docs/CommandGuide/llvm-ifs.rst (+1-1)
  • (modified) llvm/docs/CommandGuide/llvm-locstats.rst (+1-1)
  • (modified) llvm/docs/CommandGuide/llvm-mca.rst (+6-6)
  • (modified) llvm/docs/CommandGuide/llvm-profdata.rst (+1-1)
  • (modified) llvm/docs/CommandGuide/llvm-symbolizer.rst (+2-2)
  • (modified) llvm/docs/DirectX/DXContainer.rst (+1-1)
  • (modified) llvm/docs/Frontend/PerformanceTips.rst (+1-1)
  • (modified) llvm/docs/FuzzingLLVM.rst (+1-1)
  • (modified) llvm/docs/GettingStarted.rst (+2-2)
  • (modified) llvm/docs/GlobalISel/GMIR.rst (+1-1)
  • (modified) llvm/docs/GlobalISel/GenericOpcode.rst (+1-1)
  • (modified) llvm/docs/GlobalISel/Pipeline.rst (+1-1)
  • (modified) llvm/docs/HowToUpdateDebugInfo.rst (+1-1)
  • (modified) llvm/docs/JITLink.rst (+1-1)
  • (modified) llvm/docs/LangRef.rst (+3-3)
  • (modified) llvm/docs/Lexicon.rst (+1-1)
  • (modified) llvm/docs/MIRLangRef.rst (+2-2)
  • (modified) llvm/docs/PDB/CodeViewTypes.rst (+1-1)
  • (modified) llvm/docs/SymbolizerMarkupFormat.rst (+1-1)
  • (modified) llvm/docs/WritingAnLLVMBackend.rst (+2-2)
  • (modified) llvm/docs/WritingAnLLVMPass.rst (+1-1)
  • (modified) llvm/docs/tutorial/MyFirstLanguageFrontend/LangImpl10.rst (+1-1)
diff --git a/llvm/docs/AMDGPUDwarfExtensionsForHeterogeneousDebugging.rst b/llvm/docs/AMDGPUDwarfExtensionsForHeterogeneousDebugging.rst
index 95ae4f74e0ead..ba670d3954561 100644
--- a/llvm/docs/AMDGPUDwarfExtensionsForHeterogeneousDebugging.rst
+++ b/llvm/docs/AMDGPUDwarfExtensionsForHeterogeneousDebugging.rst
@@ -1187,7 +1187,7 @@ There are five kinds of location storage:
   operations. It would specify the debugger information entry and byte offset
   provided by the operations.
 
-*Location descriptions are a language independent representation of addressing
+*Location descriptions are a language-independent representation of addressing
 rules.*
 
 * *They can be the result of evaluating a debugger information entry attribute
@@ -1523,8 +1523,8 @@ expression.
       states that relocation of references from one executable or shared object
       file to another must be performed by the consumer. But given that DR is
       defined as an offset in a ``.debug_info`` section this seems impossible.
-      If DR was defined as an implementation defined value, then the consumer
-      could choose to interpret the value in an implementation defined manner to
+      If DR was defined as an implementation-defined value, then the consumer
+      could choose to interpret the value in an implementation-defined manner to
       reference a debug information in another executable or shared object.
 
       In ELF the ``.debug_info`` section is in a non-\ ``PT_LOAD`` segment so
@@ -4188,7 +4188,7 @@ The register rules are:
     conversion as the bit contents of the register is simply interpreted as a
     value of the address.
 
-    GDB has a per register hook that allows a target specific conversion on a
+    GDB has a per register hook that allows a target-specific conversion on a
     register by register basis. It defaults to truncation of bigger registers,
     and to actually reading bytes from the next register (or reads out of bounds
     for the last register) for smaller registers. There are no GDB tests that
diff --git a/llvm/docs/AMDGPUUsage.rst b/llvm/docs/AMDGPUUsage.rst
index d13f95bf37b51..f53e45dc45178 100644
--- a/llvm/docs/AMDGPUUsage.rst
+++ b/llvm/docs/AMDGPUUsage.rst
@@ -1887,7 +1887,7 @@ The AMDGPU backend supports the following calling conventions:
 AMDGPU MCExpr
 -------------
 
-As part of the AMDGPU MC layer, AMDGPU provides the following target specific
+As part of the AMDGPU MC layer, AMDGPU provides the following target-specific
 ``MCExpr``\s.
 
   .. table:: AMDGPU MCExpr types:
diff --git a/llvm/docs/CodeGenerator.rst b/llvm/docs/CodeGenerator.rst
index 020eb09ba7e1e..8260b5c173422 100644
--- a/llvm/docs/CodeGenerator.rst
+++ b/llvm/docs/CodeGenerator.rst
@@ -323,7 +323,7 @@ provide one of these objects through the ``getJITInfo`` method.
 Machine code description classes
 ================================
 
-At the high-level, LLVM code is translated to a machine specific representation
+At the high-level, LLVM code is translated to a machine-specific representation
 formed out of :raw-html:`<tt>` `MachineFunction`_ :raw-html:`</tt>`,
 :raw-html:`<tt>` `MachineBasicBlock`_ :raw-html:`</tt>`, and :raw-html:`<tt>`
 `MachineInstr`_ :raw-html:`</tt>` instances (defined in
@@ -462,7 +462,7 @@ code:
   ret
 
 This approach is extremely general (if it can handle the X86 architecture, it
-can handle anything!) and allows all of the target specific knowledge about the
+can handle anything!) and allows all of the target-specific knowledge about the
 instruction stream to be isolated in the instruction selector.  Note that
 physical registers should have a short lifetime for good code generation, and
 all physical registers are assumed dead on entry to and exit from basic blocks
@@ -634,7 +634,7 @@ file (MCObjectStreamer).  MCAsmStreamer is a straightforward implementation
 that prints out a directive for each method (e.g. ``EmitValue -> .byte``), but
 MCObjectStreamer implements a full assembler.
 
-For target specific directives, the MCStreamer has a MCTargetStreamer instance.
+For target-specific directives, the MCStreamer has a MCTargetStreamer instance.
 Each target that needs it defines a class that inherits from it and is a lot
 like MCStreamer itself: It has one method per directive and two classes that
 inherit from it, a target object streamer and a target asm streamer. The target
diff --git a/llvm/docs/CommandGuide/llvm-bcanalyzer.rst b/llvm/docs/CommandGuide/llvm-bcanalyzer.rst
index 8f15e03db3b02..1e0b581574a3a 100644
--- a/llvm/docs/CommandGuide/llvm-bcanalyzer.rst
+++ b/llvm/docs/CommandGuide/llvm-bcanalyzer.rst
@@ -14,7 +14,7 @@ DESCRIPTION
 The :program:`llvm-bcanalyzer` command is a small utility for analyzing bitcode
 files.  The tool reads a bitcode file (such as generated with the
 :program:`llvm-as` tool) and produces a statistical report on the contents of
-the bitcode file.  The tool can also dump a low level but human readable
+the bitcode file.  The tool can also dump a low level but human-readable
 version of the bitcode file.  This tool is probably not of much interest or
 utility except for those working directly with the bitcode file format.  Most
 LLVM users can just ignore this tool.
@@ -30,7 +30,7 @@ OPTIONS
 
 .. option:: --dump
 
- Causes :program:`llvm-bcanalyzer` to dump the bitcode in a human readable
+ Causes :program:`llvm-bcanalyzer` to dump the bitcode in a human-readable
  format.  This format is significantly different from LLVM assembly and
  provides details about the encoding of the bitcode file.
 
diff --git a/llvm/docs/CommandGuide/llvm-debuginfo-analyzer.rst b/llvm/docs/CommandGuide/llvm-debuginfo-analyzer.rst
index 1264f80206618..6a4e3483811d8 100644
--- a/llvm/docs/CommandGuide/llvm-debuginfo-analyzer.rst
+++ b/llvm/docs/CommandGuide/llvm-debuginfo-analyzer.rst
@@ -14,7 +14,7 @@ DESCRIPTION
 -----------
 :program:`llvm-debuginfo-analyzer` parses debug and text sections in
 binary object files and prints their contents in a logical view, which
-is a human readable representation that closely matches the structure
+is a human-readable representation that closely matches the structure
 of the original user source code. Supported object file formats include
 ELF, Mach-O, WebAssembly, PDB and COFF.
 
diff --git a/llvm/docs/CommandGuide/llvm-exegesis.rst b/llvm/docs/CommandGuide/llvm-exegesis.rst
index 25e89694b017e..5996026a1deac 100644
--- a/llvm/docs/CommandGuide/llvm-exegesis.rst
+++ b/llvm/docs/CommandGuide/llvm-exegesis.rst
@@ -106,7 +106,7 @@ properly.
   using the loop repetition mode. :program:`llvm-exegesis` needs to keep track
   of the current loop iteration within the loop repetition mode in a performant
   manner (i.e., no memory accesses), and uses a register to do this. This register
-  has an architecture specific default (e.g., `R8` on X86), but this might conflict
+  has an architecture-specific default (e.g., `R8` on X86), but this might conflict
   with some snippets. This annotation allows changing the register to prevent
   interference between the loop index register and the snippet.
 
diff --git a/llvm/docs/CommandGuide/llvm-ifs.rst b/llvm/docs/CommandGuide/llvm-ifs.rst
index 1fe81c20e15dd..e3582b365b61d 100644
--- a/llvm/docs/CommandGuide/llvm-ifs.rst
+++ b/llvm/docs/CommandGuide/llvm-ifs.rst
@@ -11,7 +11,7 @@ SYNOPSIS
 DESCRIPTION
 -----------
 
-:program:`llvm-ifs` is a tool that jointly produces human readable text-based
+:program:`llvm-ifs` is a tool that jointly produces human-readable text-based
 stubs (.ifs files) for shared objects and linkable shared object stubs
 (.so files) from either ELF shared objects or text-based stubs. The text-based
 stubs is useful for monitoring ABI changes of the shared object. The linkable
diff --git a/llvm/docs/CommandGuide/llvm-locstats.rst b/llvm/docs/CommandGuide/llvm-locstats.rst
index 3186566e449d5..7f436c1f44a7e 100644
--- a/llvm/docs/CommandGuide/llvm-locstats.rst
+++ b/llvm/docs/CommandGuide/llvm-locstats.rst
@@ -13,7 +13,7 @@ DESCRIPTION
 
 :program:`llvm-locstats` works like a wrapper around :program:`llvm-dwarfdump`.
 It parses :program:`llvm-dwarfdump` statistics regarding debug location by
-pretty printing it in a more human readable way.
+pretty printing it in a more human-readable way.
 
 The line 0% shows the number and the percentage of DIEs with no location
 information, but the line 100% shows the information for DIEs where there is
diff --git a/llvm/docs/CommandGuide/llvm-mca.rst b/llvm/docs/CommandGuide/llvm-mca.rst
index bea19317ebd61..1daae5d064aca 100644
--- a/llvm/docs/CommandGuide/llvm-mca.rst
+++ b/llvm/docs/CommandGuide/llvm-mca.rst
@@ -241,7 +241,7 @@ option specifies "``-``", then the output will also be sent to standard output.
 .. option:: -disable-cb
 
   Force usage of the generic CustomBehaviour and InstrPostProcess classes rather
-  than using the target specific implementation. The generic classes never
+  than using the target-specific implementation. The generic classes never
   detect any custom hazards or make any post processing modifications to
   instructions.
 
@@ -1125,9 +1125,9 @@ CustomBehaviour class can be used in these cases to enforce proper
 instruction modeling (often by customizing data dependencies and detecting
 hazards that :program:`llvm-mca` has no way of knowing about).
 
-:program:`llvm-mca` comes with one generic and multiple target specific
+:program:`llvm-mca` comes with one generic and multiple target-specific
 CustomBehaviour classes. The generic class will be used if the ``-disable-cb``
-flag is used or if a target specific CustomBehaviour class doesn't exist for
+flag is used or if a target-specific CustomBehaviour class doesn't exist for
 that target. (The generic class does nothing.) Currently, the CustomBehaviour
 class is only a part of the in-order pipeline, but there are plans to add it
 to the out-of-order pipeline in the future.
@@ -1141,7 +1141,7 @@ if you don't know the exact number and a value of 0 represents no stall).
 
 If you'd like to add a CustomBehaviour class for a target that doesn't
 already have one, refer to an existing implementation to see how to set it
-up. The classes are implemented within the target specific backend (for
+up. The classes are implemented within the target-specific backend (for
 example `/llvm/lib/Target/AMDGPU/MCA/`) so that they can access backend symbols.
 
 Instrument Manager
@@ -1177,12 +1177,12 @@ classes (MCSubtargetInfo, MCInstrInfo, etc.), please add it to the
 AND requires unexposed backend symbols or functionality, you can define it in
 the `/lib/Target/<TargetName>/MCA/` directory.
 
-To enable this target specific View, you will have to use this target's
+To enable this target-specific View, you will have to use this target's
 CustomBehaviour class to override the `CustomBehaviour::getViews()` methods.
 There are 3 variations of these methods based on where you want your View to
 appear in the output: `getStartViews()`, `getPostInstrInfoViews()`, and
 `getEndViews()`. These methods returns a vector of Views so you will want to
-return a vector containing all of the target specific Views for the target in
+return a vector containing all of the target-specific Views for the target in
 question.
 
 Because these target specific (and backend dependent) Views require the
diff --git a/llvm/docs/CommandGuide/llvm-profdata.rst b/llvm/docs/CommandGuide/llvm-profdata.rst
index b2c0457195631..0b1cd02e2230f 100644
--- a/llvm/docs/CommandGuide/llvm-profdata.rst
+++ b/llvm/docs/CommandGuide/llvm-profdata.rst
@@ -338,7 +338,7 @@ OPTIONS
 
  Instruct the profile dumper to show profile counts in the text format of the
  instrumentation-based profile data representation. By default, the profile
- information is dumped in a more human readable form (also in text) with
+ information is dumped in a more human-readable form (also in text) with
  annotations.
 
 .. option:: --topn=<n>
diff --git a/llvm/docs/CommandGuide/llvm-symbolizer.rst b/llvm/docs/CommandGuide/llvm-symbolizer.rst
index 2da1b2470a83e..fb86a694f5d3c 100644
--- a/llvm/docs/CommandGuide/llvm-symbolizer.rst
+++ b/llvm/docs/CommandGuide/llvm-symbolizer.rst
@@ -371,7 +371,7 @@ OPTIONS
   * Prints an address's debug-data discriminator when it is non-zero. One way to
     produce discriminators is to compile with clang's -fdebug-info-for-profiling.
 
-  ``JSON`` style provides a machine readable output in JSON. If addresses are
+  ``JSON`` style provides a machine-readable output in JSON. If addresses are
     supplied via stdin, the output JSON will be a series of individual objects.
     Otherwise, all results will be contained in a single array.
 
@@ -444,7 +444,7 @@ OPTIONS
 
 .. option:: --pretty-print, -p
 
-  Print human readable output. If :option:`--inlining` is specified, the
+  Print human-readable output. If :option:`--inlining` is specified, the
   enclosing scope is prefixed by (inlined by).
   For JSON output, the option will cause JSON to be indented and split over
   new lines. Otherwise, the JSON output will be printed in a compact form.
diff --git a/llvm/docs/DirectX/DXContainer.rst b/llvm/docs/DirectX/DXContainer.rst
index 4ace8a13dd89f..17452d99e1d99 100644
--- a/llvm/docs/DirectX/DXContainer.rst
+++ b/llvm/docs/DirectX/DXContainer.rst
@@ -280,7 +280,7 @@ elements are:
    This represents ``f5`` in the source.
 
 The LLVM ``obj2yaml`` tool can parse this data out of the PSV and present it in
-human readable YAML. For the example above it produces the output:
+human-readable YAML. For the example above it produces the output:
 
 .. code-block:: YAML
 
diff --git a/llvm/docs/Frontend/PerformanceTips.rst b/llvm/docs/Frontend/PerformanceTips.rst
index 4baf127bf050b..b81df707a31a6 100644
--- a/llvm/docs/Frontend/PerformanceTips.rst
+++ b/llvm/docs/Frontend/PerformanceTips.rst
@@ -35,7 +35,7 @@ The Basics
 ^^^^^^^^^^^
 
 #. Make sure that your Modules contain both a data layout specification and
-   target triple. Without these pieces, non of the target specific optimization
+   target triple. Without these pieces, non of the target-specific optimization
    will be enabled.  This can have a major effect on the generated code quality.
 
 #. For each function or global emitted, use the most private linkage type
diff --git a/llvm/docs/FuzzingLLVM.rst b/llvm/docs/FuzzingLLVM.rst
index 6b32eeab1241d..a0355d7014c8d 100644
--- a/llvm/docs/FuzzingLLVM.rst
+++ b/llvm/docs/FuzzingLLVM.rst
@@ -128,7 +128,7 @@ llvm-mc-assemble-fuzzer
 -----------------------
 
 A |generic fuzzer| that fuzzes the MC layer's assemblers by treating inputs as
-target specific assembly.
+target-specific assembly.
 
 Note that this fuzzer has an unusual command line interface which is not fully
 compatible with all of libFuzzer's features. Fuzzer arguments must be passed
diff --git a/llvm/docs/GettingStarted.rst b/llvm/docs/GettingStarted.rst
index e4dbb64b0b6f4..8d0adf3585a78 100644
--- a/llvm/docs/GettingStarted.rst
+++ b/llvm/docs/GettingStarted.rst
@@ -919,11 +919,11 @@ the `Command Guide <CommandGuide/index.html>`_.
 
 ``llvm-as``
 
-  The assembler transforms the human readable LLVM assembly to LLVM bitcode.
+  The assembler transforms the human-readable LLVM assembly to LLVM bitcode.
 
 ``llvm-dis``
 
-  The disassembler transforms the LLVM bitcode to human readable LLVM assembly.
+  The disassembler transforms the LLVM bitcode to human-readable LLVM assembly.
 
 ``llvm-link``
 
diff --git a/llvm/docs/GlobalISel/GMIR.rst b/llvm/docs/GlobalISel/GMIR.rst
index 633dfb87adbc7..be7e677a60354 100644
--- a/llvm/docs/GlobalISel/GMIR.rst
+++ b/llvm/docs/GlobalISel/GMIR.rst
@@ -26,7 +26,7 @@ Generic Machine Instructions
   Reference.
 
 Whereas MIR deals largely in Target Instructions and only has a small set of
-target independent opcodes such as ``COPY``, ``PHI``, and ``REG_SEQUENCE``,
+target-independent opcodes such as ``COPY``, ``PHI``, and ``REG_SEQUENCE``,
 gMIR defines a rich collection of ``Generic Opcodes`` which are target
 independent and describe operations which are typically supported by targets.
 One example is ``G_ADD`` which is the generic opcode for an integer addition.
diff --git a/llvm/docs/GlobalISel/GenericOpcode.rst b/llvm/docs/GlobalISel/GenericOpcode.rst
index 4816094fd4b6b..eefd76de9c33a 100644
--- a/llvm/docs/GlobalISel/GenericOpcode.rst
+++ b/llvm/docs/GlobalISel/GenericOpcode.rst
@@ -1105,7 +1105,7 @@ G_TRAP, G_DEBUGTRAP, G_UBSANTRAP
 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
 
 Represents :ref:`llvm.trap <llvm.trap>`, :ref:`llvm.debugtrap <llvm.debugtrap>`
-and :ref:`llvm.ubsantrap <llvm.ubsantrap>` that generate a target dependent
+and :ref:`llvm.ubsantrap <llvm.ubsantrap>` that generate a target-dependent
 trap instructions.
 
 .. code-block:: none
diff --git a/llvm/docs/GlobalISel/Pipeline.rst b/llvm/docs/GlobalISel/Pipeline.rst
index 01bd4df85d72f..b9085e82f1428 100644
--- a/llvm/docs/GlobalISel/Pipeline.rst
+++ b/llvm/docs/GlobalISel/Pipeline.rst
@@ -80,7 +80,7 @@ Combiner
   alternatives but Combiners can also focus on code size or other metrics.
 
 Additional passes such as these can be inserted to support higher optimization
-levels or target specific needs. A likely pipeline is:
+levels or target-specific needs. A likely pipeline is:
 
 .. image:: pipeline-overview-with-combiners.png
 
diff --git a/llvm/docs/HowToUpdateDebugInfo.rst b/llvm/docs/HowToUpdateDebugInfo.rst
index 915e2896023c5..ca420e709d556 100644
--- a/llvm/docs/HowToUpdateDebugInfo.rst
+++ b/llvm/docs/HowToUpdateDebugInfo.rst
@@ -499,7 +499,7 @@ a JSON file as follows:
   $ opt -verify-debuginfo-preserve -verify-di-preserve-export=sample.json -pass-to-test sample.ll
 
 and then use the ``llvm/utils/llvm-original-di-preservation.py`` script
-to generate an HTML page with the issues reported in a more human readable form
+to generate an HTML page with the issues reported in a more human-readable form
 as follows:
 
 .. code-block:: bash
diff --git a/llvm/docs/JITLink.rst b/llvm/docs/JITLink.rst
index 89027123f4750..370281bcaef6c 100644
--- a/llvm/docs/JITLink.rst
+++ b/llvm/docs/JITLink.rst
@@ -1072,7 +1072,7 @@ Major outstanding projects include:
 
 * Refactor architecture support to maximize sharing across formats.
 
-  All formats should be able to share the bulk of the architecture specific
+  All formats should be able to share the bulk of the architecture-specific
   code (especially relocations) for each supported architecture.
 
 * Refactor ELF link graph construction.
diff --git a/llvm/docs/LangRef.rst b/llvm/docs/LangRef.rst
index bac13cc0424a6..2a6530f33d382 100644
--- a/llvm/docs/LangRef.rst
+++ b/llvm/docs/LangRef.rst
@@ -26,7 +26,7 @@ readable assembly language representation. This allows LLVM to provide a
 powerful intermediate representation for efficient compiler
 transformations and analysis, while providing a natural means to debug
 and visualize the transformations. The three different forms of LLVM are
-all equivalent. This document describes the human readable
+all equivalent. This document describes the human-readable
 representation and notation.
 
 The LLVM representation aims to be light-weight and low-level while
@@ -21287,7 +21287,7 @@ Semantics:
 On some architectures the address of the code to be executed needs to be
 different than the address where the trampoline is actually stored. This
 intrinsic returns the executable address corresponding to ``tramp``
-after performing the required machine specific adjustments. The pointer
+after performing the required machine-specific adjustments. The pointer
 returned can then be :ref:`bitcast and executed <int_trampoline>`.
 
 
@@ -29378,7 +29378,7 @@ None.
 Semantics:
 """"""""""
 
-This intrinsic is lowered to the target dependent trap instruction. If
+This intrinsic is lowered to the target-dependent trap instruction. If
 the target does not have a trap instruction, this intrinsic will be
 lowered to a call of the ``abort()`` function.
 
diff --git a/llvm/docs/Lexicon.rst b/llvm/docs/Lexicon.rst
index 1d4894f78ca88..05315a82b55a1 100644
--- a/llvm/docs/Lexicon.rst
+++ b/llvm/docs/Lexicon.rst
@@ -192,7 +192,7 @@ L
 **LSDA**
     Language Specific Data Area.  C++ "zero cost" unwinding is built on top a
     generic unwinding mechanism.  As the unwinder walks each frame, it calls
-    a "personality" function to do language specific analysis.  Each function's
+    a "personality" function to do language-specific analysis.  Each function's
     FDE points ...
[truncated]

@llvmbot
Copy link
Member

llvmbot commented Jul 29, 2025

@llvm/pr-subscribers-backend-directx

Author: Kazu Hirata (kazutakahirata)

Changes

This patch hyphenates words that are used as adjecives, such as:

  • architecture specific
  • human readable
  • implementation defined
  • language independent
  • language specific
  • machine readable
  • machine specific
  • target independent
  • target specific

Patch is 25.21 KiB, truncated to 20.00 KiB below, full version: https://github.com/llvm/llvm-project/pull/151087.diff

28 Files Affected:

  • (modified) llvm/docs/AMDGPUDwarfExtensionsForHeterogeneousDebugging.rst (+4-4)
  • (modified) llvm/docs/AMDGPUUsage.rst (+1-1)
  • (modified) llvm/docs/CodeGenerator.rst (+3-3)
  • (modified) llvm/docs/CommandGuide/llvm-bcanalyzer.rst (+2-2)
  • (modified) llvm/docs/CommandGuide/llvm-debuginfo-analyzer.rst (+1-1)
  • (modified) llvm/docs/CommandGuide/llvm-exegesis.rst (+1-1)
  • (modified) llvm/docs/CommandGuide/llvm-ifs.rst (+1-1)
  • (modified) llvm/docs/CommandGuide/llvm-locstats.rst (+1-1)
  • (modified) llvm/docs/CommandGuide/llvm-mca.rst (+6-6)
  • (modified) llvm/docs/CommandGuide/llvm-profdata.rst (+1-1)
  • (modified) llvm/docs/CommandGuide/llvm-symbolizer.rst (+2-2)
  • (modified) llvm/docs/DirectX/DXContainer.rst (+1-1)
  • (modified) llvm/docs/Frontend/PerformanceTips.rst (+1-1)
  • (modified) llvm/docs/FuzzingLLVM.rst (+1-1)
  • (modified) llvm/docs/GettingStarted.rst (+2-2)
  • (modified) llvm/docs/GlobalISel/GMIR.rst (+1-1)
  • (modified) llvm/docs/GlobalISel/GenericOpcode.rst (+1-1)
  • (modified) llvm/docs/GlobalISel/Pipeline.rst (+1-1)
  • (modified) llvm/docs/HowToUpdateDebugInfo.rst (+1-1)
  • (modified) llvm/docs/JITLink.rst (+1-1)
  • (modified) llvm/docs/LangRef.rst (+3-3)
  • (modified) llvm/docs/Lexicon.rst (+1-1)
  • (modified) llvm/docs/MIRLangRef.rst (+2-2)
  • (modified) llvm/docs/PDB/CodeViewTypes.rst (+1-1)
  • (modified) llvm/docs/SymbolizerMarkupFormat.rst (+1-1)
  • (modified) llvm/docs/WritingAnLLVMBackend.rst (+2-2)
  • (modified) llvm/docs/WritingAnLLVMPass.rst (+1-1)
  • (modified) llvm/docs/tutorial/MyFirstLanguageFrontend/LangImpl10.rst (+1-1)
diff --git a/llvm/docs/AMDGPUDwarfExtensionsForHeterogeneousDebugging.rst b/llvm/docs/AMDGPUDwarfExtensionsForHeterogeneousDebugging.rst
index 95ae4f74e0ead..ba670d3954561 100644
--- a/llvm/docs/AMDGPUDwarfExtensionsForHeterogeneousDebugging.rst
+++ b/llvm/docs/AMDGPUDwarfExtensionsForHeterogeneousDebugging.rst
@@ -1187,7 +1187,7 @@ There are five kinds of location storage:
   operations. It would specify the debugger information entry and byte offset
   provided by the operations.
 
-*Location descriptions are a language independent representation of addressing
+*Location descriptions are a language-independent representation of addressing
 rules.*
 
 * *They can be the result of evaluating a debugger information entry attribute
@@ -1523,8 +1523,8 @@ expression.
       states that relocation of references from one executable or shared object
       file to another must be performed by the consumer. But given that DR is
       defined as an offset in a ``.debug_info`` section this seems impossible.
-      If DR was defined as an implementation defined value, then the consumer
-      could choose to interpret the value in an implementation defined manner to
+      If DR was defined as an implementation-defined value, then the consumer
+      could choose to interpret the value in an implementation-defined manner to
       reference a debug information in another executable or shared object.
 
       In ELF the ``.debug_info`` section is in a non-\ ``PT_LOAD`` segment so
@@ -4188,7 +4188,7 @@ The register rules are:
     conversion as the bit contents of the register is simply interpreted as a
     value of the address.
 
-    GDB has a per register hook that allows a target specific conversion on a
+    GDB has a per register hook that allows a target-specific conversion on a
     register by register basis. It defaults to truncation of bigger registers,
     and to actually reading bytes from the next register (or reads out of bounds
     for the last register) for smaller registers. There are no GDB tests that
diff --git a/llvm/docs/AMDGPUUsage.rst b/llvm/docs/AMDGPUUsage.rst
index d13f95bf37b51..f53e45dc45178 100644
--- a/llvm/docs/AMDGPUUsage.rst
+++ b/llvm/docs/AMDGPUUsage.rst
@@ -1887,7 +1887,7 @@ The AMDGPU backend supports the following calling conventions:
 AMDGPU MCExpr
 -------------
 
-As part of the AMDGPU MC layer, AMDGPU provides the following target specific
+As part of the AMDGPU MC layer, AMDGPU provides the following target-specific
 ``MCExpr``\s.
 
   .. table:: AMDGPU MCExpr types:
diff --git a/llvm/docs/CodeGenerator.rst b/llvm/docs/CodeGenerator.rst
index 020eb09ba7e1e..8260b5c173422 100644
--- a/llvm/docs/CodeGenerator.rst
+++ b/llvm/docs/CodeGenerator.rst
@@ -323,7 +323,7 @@ provide one of these objects through the ``getJITInfo`` method.
 Machine code description classes
 ================================
 
-At the high-level, LLVM code is translated to a machine specific representation
+At the high-level, LLVM code is translated to a machine-specific representation
 formed out of :raw-html:`<tt>` `MachineFunction`_ :raw-html:`</tt>`,
 :raw-html:`<tt>` `MachineBasicBlock`_ :raw-html:`</tt>`, and :raw-html:`<tt>`
 `MachineInstr`_ :raw-html:`</tt>` instances (defined in
@@ -462,7 +462,7 @@ code:
   ret
 
 This approach is extremely general (if it can handle the X86 architecture, it
-can handle anything!) and allows all of the target specific knowledge about the
+can handle anything!) and allows all of the target-specific knowledge about the
 instruction stream to be isolated in the instruction selector.  Note that
 physical registers should have a short lifetime for good code generation, and
 all physical registers are assumed dead on entry to and exit from basic blocks
@@ -634,7 +634,7 @@ file (MCObjectStreamer).  MCAsmStreamer is a straightforward implementation
 that prints out a directive for each method (e.g. ``EmitValue -> .byte``), but
 MCObjectStreamer implements a full assembler.
 
-For target specific directives, the MCStreamer has a MCTargetStreamer instance.
+For target-specific directives, the MCStreamer has a MCTargetStreamer instance.
 Each target that needs it defines a class that inherits from it and is a lot
 like MCStreamer itself: It has one method per directive and two classes that
 inherit from it, a target object streamer and a target asm streamer. The target
diff --git a/llvm/docs/CommandGuide/llvm-bcanalyzer.rst b/llvm/docs/CommandGuide/llvm-bcanalyzer.rst
index 8f15e03db3b02..1e0b581574a3a 100644
--- a/llvm/docs/CommandGuide/llvm-bcanalyzer.rst
+++ b/llvm/docs/CommandGuide/llvm-bcanalyzer.rst
@@ -14,7 +14,7 @@ DESCRIPTION
 The :program:`llvm-bcanalyzer` command is a small utility for analyzing bitcode
 files.  The tool reads a bitcode file (such as generated with the
 :program:`llvm-as` tool) and produces a statistical report on the contents of
-the bitcode file.  The tool can also dump a low level but human readable
+the bitcode file.  The tool can also dump a low level but human-readable
 version of the bitcode file.  This tool is probably not of much interest or
 utility except for those working directly with the bitcode file format.  Most
 LLVM users can just ignore this tool.
@@ -30,7 +30,7 @@ OPTIONS
 
 .. option:: --dump
 
- Causes :program:`llvm-bcanalyzer` to dump the bitcode in a human readable
+ Causes :program:`llvm-bcanalyzer` to dump the bitcode in a human-readable
  format.  This format is significantly different from LLVM assembly and
  provides details about the encoding of the bitcode file.
 
diff --git a/llvm/docs/CommandGuide/llvm-debuginfo-analyzer.rst b/llvm/docs/CommandGuide/llvm-debuginfo-analyzer.rst
index 1264f80206618..6a4e3483811d8 100644
--- a/llvm/docs/CommandGuide/llvm-debuginfo-analyzer.rst
+++ b/llvm/docs/CommandGuide/llvm-debuginfo-analyzer.rst
@@ -14,7 +14,7 @@ DESCRIPTION
 -----------
 :program:`llvm-debuginfo-analyzer` parses debug and text sections in
 binary object files and prints their contents in a logical view, which
-is a human readable representation that closely matches the structure
+is a human-readable representation that closely matches the structure
 of the original user source code. Supported object file formats include
 ELF, Mach-O, WebAssembly, PDB and COFF.
 
diff --git a/llvm/docs/CommandGuide/llvm-exegesis.rst b/llvm/docs/CommandGuide/llvm-exegesis.rst
index 25e89694b017e..5996026a1deac 100644
--- a/llvm/docs/CommandGuide/llvm-exegesis.rst
+++ b/llvm/docs/CommandGuide/llvm-exegesis.rst
@@ -106,7 +106,7 @@ properly.
   using the loop repetition mode. :program:`llvm-exegesis` needs to keep track
   of the current loop iteration within the loop repetition mode in a performant
   manner (i.e., no memory accesses), and uses a register to do this. This register
-  has an architecture specific default (e.g., `R8` on X86), but this might conflict
+  has an architecture-specific default (e.g., `R8` on X86), but this might conflict
   with some snippets. This annotation allows changing the register to prevent
   interference between the loop index register and the snippet.
 
diff --git a/llvm/docs/CommandGuide/llvm-ifs.rst b/llvm/docs/CommandGuide/llvm-ifs.rst
index 1fe81c20e15dd..e3582b365b61d 100644
--- a/llvm/docs/CommandGuide/llvm-ifs.rst
+++ b/llvm/docs/CommandGuide/llvm-ifs.rst
@@ -11,7 +11,7 @@ SYNOPSIS
 DESCRIPTION
 -----------
 
-:program:`llvm-ifs` is a tool that jointly produces human readable text-based
+:program:`llvm-ifs` is a tool that jointly produces human-readable text-based
 stubs (.ifs files) for shared objects and linkable shared object stubs
 (.so files) from either ELF shared objects or text-based stubs. The text-based
 stubs is useful for monitoring ABI changes of the shared object. The linkable
diff --git a/llvm/docs/CommandGuide/llvm-locstats.rst b/llvm/docs/CommandGuide/llvm-locstats.rst
index 3186566e449d5..7f436c1f44a7e 100644
--- a/llvm/docs/CommandGuide/llvm-locstats.rst
+++ b/llvm/docs/CommandGuide/llvm-locstats.rst
@@ -13,7 +13,7 @@ DESCRIPTION
 
 :program:`llvm-locstats` works like a wrapper around :program:`llvm-dwarfdump`.
 It parses :program:`llvm-dwarfdump` statistics regarding debug location by
-pretty printing it in a more human readable way.
+pretty printing it in a more human-readable way.
 
 The line 0% shows the number and the percentage of DIEs with no location
 information, but the line 100% shows the information for DIEs where there is
diff --git a/llvm/docs/CommandGuide/llvm-mca.rst b/llvm/docs/CommandGuide/llvm-mca.rst
index bea19317ebd61..1daae5d064aca 100644
--- a/llvm/docs/CommandGuide/llvm-mca.rst
+++ b/llvm/docs/CommandGuide/llvm-mca.rst
@@ -241,7 +241,7 @@ option specifies "``-``", then the output will also be sent to standard output.
 .. option:: -disable-cb
 
   Force usage of the generic CustomBehaviour and InstrPostProcess classes rather
-  than using the target specific implementation. The generic classes never
+  than using the target-specific implementation. The generic classes never
   detect any custom hazards or make any post processing modifications to
   instructions.
 
@@ -1125,9 +1125,9 @@ CustomBehaviour class can be used in these cases to enforce proper
 instruction modeling (often by customizing data dependencies and detecting
 hazards that :program:`llvm-mca` has no way of knowing about).
 
-:program:`llvm-mca` comes with one generic and multiple target specific
+:program:`llvm-mca` comes with one generic and multiple target-specific
 CustomBehaviour classes. The generic class will be used if the ``-disable-cb``
-flag is used or if a target specific CustomBehaviour class doesn't exist for
+flag is used or if a target-specific CustomBehaviour class doesn't exist for
 that target. (The generic class does nothing.) Currently, the CustomBehaviour
 class is only a part of the in-order pipeline, but there are plans to add it
 to the out-of-order pipeline in the future.
@@ -1141,7 +1141,7 @@ if you don't know the exact number and a value of 0 represents no stall).
 
 If you'd like to add a CustomBehaviour class for a target that doesn't
 already have one, refer to an existing implementation to see how to set it
-up. The classes are implemented within the target specific backend (for
+up. The classes are implemented within the target-specific backend (for
 example `/llvm/lib/Target/AMDGPU/MCA/`) so that they can access backend symbols.
 
 Instrument Manager
@@ -1177,12 +1177,12 @@ classes (MCSubtargetInfo, MCInstrInfo, etc.), please add it to the
 AND requires unexposed backend symbols or functionality, you can define it in
 the `/lib/Target/<TargetName>/MCA/` directory.
 
-To enable this target specific View, you will have to use this target's
+To enable this target-specific View, you will have to use this target's
 CustomBehaviour class to override the `CustomBehaviour::getViews()` methods.
 There are 3 variations of these methods based on where you want your View to
 appear in the output: `getStartViews()`, `getPostInstrInfoViews()`, and
 `getEndViews()`. These methods returns a vector of Views so you will want to
-return a vector containing all of the target specific Views for the target in
+return a vector containing all of the target-specific Views for the target in
 question.
 
 Because these target specific (and backend dependent) Views require the
diff --git a/llvm/docs/CommandGuide/llvm-profdata.rst b/llvm/docs/CommandGuide/llvm-profdata.rst
index b2c0457195631..0b1cd02e2230f 100644
--- a/llvm/docs/CommandGuide/llvm-profdata.rst
+++ b/llvm/docs/CommandGuide/llvm-profdata.rst
@@ -338,7 +338,7 @@ OPTIONS
 
  Instruct the profile dumper to show profile counts in the text format of the
  instrumentation-based profile data representation. By default, the profile
- information is dumped in a more human readable form (also in text) with
+ information is dumped in a more human-readable form (also in text) with
  annotations.
 
 .. option:: --topn=<n>
diff --git a/llvm/docs/CommandGuide/llvm-symbolizer.rst b/llvm/docs/CommandGuide/llvm-symbolizer.rst
index 2da1b2470a83e..fb86a694f5d3c 100644
--- a/llvm/docs/CommandGuide/llvm-symbolizer.rst
+++ b/llvm/docs/CommandGuide/llvm-symbolizer.rst
@@ -371,7 +371,7 @@ OPTIONS
   * Prints an address's debug-data discriminator when it is non-zero. One way to
     produce discriminators is to compile with clang's -fdebug-info-for-profiling.
 
-  ``JSON`` style provides a machine readable output in JSON. If addresses are
+  ``JSON`` style provides a machine-readable output in JSON. If addresses are
     supplied via stdin, the output JSON will be a series of individual objects.
     Otherwise, all results will be contained in a single array.
 
@@ -444,7 +444,7 @@ OPTIONS
 
 .. option:: --pretty-print, -p
 
-  Print human readable output. If :option:`--inlining` is specified, the
+  Print human-readable output. If :option:`--inlining` is specified, the
   enclosing scope is prefixed by (inlined by).
   For JSON output, the option will cause JSON to be indented and split over
   new lines. Otherwise, the JSON output will be printed in a compact form.
diff --git a/llvm/docs/DirectX/DXContainer.rst b/llvm/docs/DirectX/DXContainer.rst
index 4ace8a13dd89f..17452d99e1d99 100644
--- a/llvm/docs/DirectX/DXContainer.rst
+++ b/llvm/docs/DirectX/DXContainer.rst
@@ -280,7 +280,7 @@ elements are:
    This represents ``f5`` in the source.
 
 The LLVM ``obj2yaml`` tool can parse this data out of the PSV and present it in
-human readable YAML. For the example above it produces the output:
+human-readable YAML. For the example above it produces the output:
 
 .. code-block:: YAML
 
diff --git a/llvm/docs/Frontend/PerformanceTips.rst b/llvm/docs/Frontend/PerformanceTips.rst
index 4baf127bf050b..b81df707a31a6 100644
--- a/llvm/docs/Frontend/PerformanceTips.rst
+++ b/llvm/docs/Frontend/PerformanceTips.rst
@@ -35,7 +35,7 @@ The Basics
 ^^^^^^^^^^^
 
 #. Make sure that your Modules contain both a data layout specification and
-   target triple. Without these pieces, non of the target specific optimization
+   target triple. Without these pieces, non of the target-specific optimization
    will be enabled.  This can have a major effect on the generated code quality.
 
 #. For each function or global emitted, use the most private linkage type
diff --git a/llvm/docs/FuzzingLLVM.rst b/llvm/docs/FuzzingLLVM.rst
index 6b32eeab1241d..a0355d7014c8d 100644
--- a/llvm/docs/FuzzingLLVM.rst
+++ b/llvm/docs/FuzzingLLVM.rst
@@ -128,7 +128,7 @@ llvm-mc-assemble-fuzzer
 -----------------------
 
 A |generic fuzzer| that fuzzes the MC layer's assemblers by treating inputs as
-target specific assembly.
+target-specific assembly.
 
 Note that this fuzzer has an unusual command line interface which is not fully
 compatible with all of libFuzzer's features. Fuzzer arguments must be passed
diff --git a/llvm/docs/GettingStarted.rst b/llvm/docs/GettingStarted.rst
index e4dbb64b0b6f4..8d0adf3585a78 100644
--- a/llvm/docs/GettingStarted.rst
+++ b/llvm/docs/GettingStarted.rst
@@ -919,11 +919,11 @@ the `Command Guide <CommandGuide/index.html>`_.
 
 ``llvm-as``
 
-  The assembler transforms the human readable LLVM assembly to LLVM bitcode.
+  The assembler transforms the human-readable LLVM assembly to LLVM bitcode.
 
 ``llvm-dis``
 
-  The disassembler transforms the LLVM bitcode to human readable LLVM assembly.
+  The disassembler transforms the LLVM bitcode to human-readable LLVM assembly.
 
 ``llvm-link``
 
diff --git a/llvm/docs/GlobalISel/GMIR.rst b/llvm/docs/GlobalISel/GMIR.rst
index 633dfb87adbc7..be7e677a60354 100644
--- a/llvm/docs/GlobalISel/GMIR.rst
+++ b/llvm/docs/GlobalISel/GMIR.rst
@@ -26,7 +26,7 @@ Generic Machine Instructions
   Reference.
 
 Whereas MIR deals largely in Target Instructions and only has a small set of
-target independent opcodes such as ``COPY``, ``PHI``, and ``REG_SEQUENCE``,
+target-independent opcodes such as ``COPY``, ``PHI``, and ``REG_SEQUENCE``,
 gMIR defines a rich collection of ``Generic Opcodes`` which are target
 independent and describe operations which are typically supported by targets.
 One example is ``G_ADD`` which is the generic opcode for an integer addition.
diff --git a/llvm/docs/GlobalISel/GenericOpcode.rst b/llvm/docs/GlobalISel/GenericOpcode.rst
index 4816094fd4b6b..eefd76de9c33a 100644
--- a/llvm/docs/GlobalISel/GenericOpcode.rst
+++ b/llvm/docs/GlobalISel/GenericOpcode.rst
@@ -1105,7 +1105,7 @@ G_TRAP, G_DEBUGTRAP, G_UBSANTRAP
 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
 
 Represents :ref:`llvm.trap <llvm.trap>`, :ref:`llvm.debugtrap <llvm.debugtrap>`
-and :ref:`llvm.ubsantrap <llvm.ubsantrap>` that generate a target dependent
+and :ref:`llvm.ubsantrap <llvm.ubsantrap>` that generate a target-dependent
 trap instructions.
 
 .. code-block:: none
diff --git a/llvm/docs/GlobalISel/Pipeline.rst b/llvm/docs/GlobalISel/Pipeline.rst
index 01bd4df85d72f..b9085e82f1428 100644
--- a/llvm/docs/GlobalISel/Pipeline.rst
+++ b/llvm/docs/GlobalISel/Pipeline.rst
@@ -80,7 +80,7 @@ Combiner
   alternatives but Combiners can also focus on code size or other metrics.
 
 Additional passes such as these can be inserted to support higher optimization
-levels or target specific needs. A likely pipeline is:
+levels or target-specific needs. A likely pipeline is:
 
 .. image:: pipeline-overview-with-combiners.png
 
diff --git a/llvm/docs/HowToUpdateDebugInfo.rst b/llvm/docs/HowToUpdateDebugInfo.rst
index 915e2896023c5..ca420e709d556 100644
--- a/llvm/docs/HowToUpdateDebugInfo.rst
+++ b/llvm/docs/HowToUpdateDebugInfo.rst
@@ -499,7 +499,7 @@ a JSON file as follows:
   $ opt -verify-debuginfo-preserve -verify-di-preserve-export=sample.json -pass-to-test sample.ll
 
 and then use the ``llvm/utils/llvm-original-di-preservation.py`` script
-to generate an HTML page with the issues reported in a more human readable form
+to generate an HTML page with the issues reported in a more human-readable form
 as follows:
 
 .. code-block:: bash
diff --git a/llvm/docs/JITLink.rst b/llvm/docs/JITLink.rst
index 89027123f4750..370281bcaef6c 100644
--- a/llvm/docs/JITLink.rst
+++ b/llvm/docs/JITLink.rst
@@ -1072,7 +1072,7 @@ Major outstanding projects include:
 
 * Refactor architecture support to maximize sharing across formats.
 
-  All formats should be able to share the bulk of the architecture specific
+  All formats should be able to share the bulk of the architecture-specific
   code (especially relocations) for each supported architecture.
 
 * Refactor ELF link graph construction.
diff --git a/llvm/docs/LangRef.rst b/llvm/docs/LangRef.rst
index bac13cc0424a6..2a6530f33d382 100644
--- a/llvm/docs/LangRef.rst
+++ b/llvm/docs/LangRef.rst
@@ -26,7 +26,7 @@ readable assembly language representation. This allows LLVM to provide a
 powerful intermediate representation for efficient compiler
 transformations and analysis, while providing a natural means to debug
 and visualize the transformations. The three different forms of LLVM are
-all equivalent. This document describes the human readable
+all equivalent. This document describes the human-readable
 representation and notation.
 
 The LLVM representation aims to be light-weight and low-level while
@@ -21287,7 +21287,7 @@ Semantics:
 On some architectures the address of the code to be executed needs to be
 different than the address where the trampoline is actually stored. This
 intrinsic returns the executable address corresponding to ``tramp``
-after performing the required machine specific adjustments. The pointer
+after performing the required machine-specific adjustments. The pointer
 returned can then be :ref:`bitcast and executed <int_trampoline>`.
 
 
@@ -29378,7 +29378,7 @@ None.
 Semantics:
 """"""""""
 
-This intrinsic is lowered to the target dependent trap instruction. If
+This intrinsic is lowered to the target-dependent trap instruction. If
 the target does not have a trap instruction, this intrinsic will be
 lowered to a call of the ``abort()`` function.
 
diff --git a/llvm/docs/Lexicon.rst b/llvm/docs/Lexicon.rst
index 1d4894f78ca88..05315a82b55a1 100644
--- a/llvm/docs/Lexicon.rst
+++ b/llvm/docs/Lexicon.rst
@@ -192,7 +192,7 @@ L
 **LSDA**
     Language Specific Data Area.  C++ "zero cost" unwinding is built on top a
     generic unwinding mechanism.  As the unwinder walks each frame, it calls
-    a "personality" function to do language specific analysis.  Each function's
+    a "personality" function to do language-specific analysis.  Each function's
     FDE points ...
[truncated]

@kazutakahirata kazutakahirata merged commit 183b380 into llvm:main Aug 1, 2025
17 checks passed
@kazutakahirata kazutakahirata deleted the cleanup_20250728_proofread_llvm branch August 1, 2025 14:02
krishna2803 pushed a commit to krishna2803/llvm-project that referenced this pull request Aug 12, 2025
This patch hyphenates words that are used as adjecives, such as:

- architecture specific
- human readable
- implementation defined
- language independent
- language specific
- machine readable
- machine specific
- target independent
- target specific
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants